The present invention relates to data processing by digital computer, and more particularly to rendering a graph of objects of existing classes.
For the purposes of this invention, rendering an object includes any transformation of an object into a different representation of the object. The different representation of the object can include a visual representation of the object that can be displayed on a screen. Rendering an object can also include transforming the object to produce an HTML document or an XML description of the object. It is possible to have many renderers for the same object, each renderer transforming the object to a different representation of the object. For example, the data contained in an object can be rendered as text displayed on the screen, as an HTML file, or as an XML file.
The need to separate an object from a visual representation of the object has been recognized in the design of applications that display objects on a screen. Such applications can be required to display a number of different visual representation of the same object. In an interactive visual application, including graphical user interface (GUI) components, any change in the object caused by user interaction with one visual representation of the object needs to be communicated to other visual representations of the object. It can also be desirable to have the ability to add new visual representations for an existing object without making significant changes to the implementation of the object itself or to existing renderers for that object. These objectives can be met by partitioning the visual applications such that there is some separation between the data contained in the object and the visual representation of the object.
The model-view-controller (MVC) architecture, illustrated in FIG. 1, represents one of the approaches for separating the data contained in an object from other aspects of the visual application. The MVC architecture breaks GUI components, that are part of a visual application, into three separate parts—a model 100, a view 105, and a controller 110. The model encompasses the state data for each component. There are different models for different classes of components. The view is the visual representation of the data. The view determines the visual appearance of the component on the screen. The controller is the portion of the user interface that dictates how the component interacts with events. The controller takes user input on the view and decides how each component will react to the event.
In the MVC architecture illustrated in FIG. 1, each of the three components—the model, the view, and the controller—requires the services of another element to keep itself continually updated. The view must obtain the data from the model in order to display the component on the screen. The view monitors the user events and determines if the component associated with the view is the recipient of user events. The view also communicates the user events directed at the component to the controller. The controller receives the user events from the view and determines the appropriate response. The controller's response to the user events may include modifying the state data in the model. The controller communicates any required changes to the state data to the model. The visual representation of the component is updated in response to the user event when the model passes the new state data to the view for display.
FIG. 2 illustrates another approach for separating an object from visual representations of that object that is used by Java™ Swing. Swing uses a simplified variant of the MVC design, called the model-delegate. Swing combines the view 215 and the controller 220 for the object into a single element, known as the UI-delegate 205, that draws the component to the screen and handles GUI events. Each Swing component 200 contains a model 210 and a UI-delegate. The model is responsible for maintaining information about the component's state. The UI-delegate is responsible for maintaining information about how to draw the component on the screen. In addition, the UI-delegate reacts to various events, including user interaction with the view, that propagate through the component. Separating the UI-delegate from the model can permit the user to select different views for the same component without changing the data contained in the model.
A model in Swing has no intrinsic knowledge of the view that represents it. A model only has a set of listeners interested in knowing when the state of the model has changed. Swing uses the separation between the model and the UI-delegate to support the pluggable look-and-feel (PLAF) architecture. The Swing toolkit provides a default look-and-feel. An application can override the default look-and-feel to dictate a particular look-and-feel. A Swing component that is displayed using the pluggable look-and-feel API is aware of the fact that it is being displayed and implements special hooks required by the look-and-feel API. Each Swing component that has a specific look-and-feel behavior defines an abstract class to represent its UI delegate. A particular look-and-feel is installed for a component by creating a UI delegate and setting it as the “UI” property for the component. Each component also provides a method which creates and sets a UI delegate for the default look-and-feel.